Embodiments of the present invention relate to event stream processing, and more particularly relate to techniques for facilitating communication between one or more client applications and an event processing server.
Event stream processing (ESP) refers to the processing of one or more streams of data (e.g., event streams) with the goal of identifying meaningful information from those streams. An event stream is a linearly-ordered, continuous sequence of events. An event in an event stream is a tuple of data that represents, or encodes, an occurrence or activity. Typically, each event in an event stream is associated with (and is linearly-ordered by) a time. An example of an event stream is a stream of stock market price data received from a stock market data feed. In this example, the events in the stream may be tuples of (<stock symbol>, <stock price>) that are generated in real-time based on the movement of the stock market. Other types of event streams may be created in other contexts and domains, such a stream of sensor readings generated by a physical sensor or probe, a stream of network traffic events generated by a network monitor, and the like.
To facilitate the processing of event streams, a number of technology vendors have developed software and/or hardware-based ESP systems. These ESP systems typically include a server application (referred to herein as an event processing server) configured to receive event stream data and to perform various operations on that data on behalf of one or more client applications. For instance, an event processing server may receive commands and/or data from a client application for instantiating a new event stream, inserting data into an event stream, executing a continuous query against an event stream, etc. The event processing server may then process those commands accordingly and return a result (if applicable) to the client application.
A problem with existing ESP systems is that there is no standard Application Programming Interface (API) for communicating information between a client application and an event processing server. For example, there is no standard API for a client application to send commands and/or event stream data to an event processing server. Similarly, there is no standard API for the server to return processing results or other information to the client application.
Some existing event processing servers expose a proprietary interface for interacting with client applications. However, a proprietary interface requires each client application to implement custom code for invoking the interface. This, in turn, makes it difficult to migrate these client applications so that they can interoperate with different event processing server implementations provided by different vendors. Further, a proprietary interface may render an event processing server incompatible with existing/legacy client applications.